1. Field of the Invention
The invention relates to computer system security and communication systems. The invention relates also to a trusted platform module. Particularly, the invention relates to a method for the remote attestation of messages in a communication system.
2. Description of the Related Art
Computer system security has become a very important topic nowadays. It has become important not only to authenticate the origin of a message, to authenticate the sender of the message or to ensure the message is not eavesdropped, but it is important to ensure the software configuration of the device that sent the message. Otherwise, there exists the possibility, for example, that the device of the sender is running an operating system or a protocol stack that has been corrupted with malicious software components. In some cases it is just verified that the device of the sender is running a potentially secure or well-known operating system environment with the components expected.
Traditional security policies are based on the identification and authentication of devices or user identities associated with the devices. A user is associated with a device, for example, using a Subscriber Identity Module (SIM). When, for example, a remote user establishes a connection to a corporate intranet, a Virtual Private Network (VPN) gateway typically identifies and authenticates the remote user before granting or denying the connection. In many cases it is useful to verify other attributes of the remote device in addition to its identity. One such attribute is the software configuration of the remote device. In the case of corporate intranet access the VPN gateway could, for example, verify that the remote device is running a correct operating system and a correct network stack with the latest security updates before granting access to the corporate intranet. This process of verifying the software configuration of a remote device is called remote attestation.
The Trusted Computing Group (TCG) has specified a hardware security component called the Trusted Platform Module (TPM). Trust may be defined as the expectation that a device will act in a particular manner for a given purpose. A TPM is a module, for example, connected to the controller of a device, the trust of which is to be determined. A TPM provides an interface that comprises protected capabilities, which are commands with exclusive access to a number of shielded locations. Shielded locations may be registers or memory locations. In a TPM there are also stored cryptographic keys that may be used by the TPM to authenticate measurements obtained from the TPM. The TPM is used to obtain attestation that a device may be trusted. Attestation is the process of vouching for the accuracy of information. The TPM provides signed reports, for example, that report measurements of the local configuration like the operating system and the standard applications in the device. The measurements start from a core root of trust for measurement that is trusted in the device. After that, each software layer measures the next software layer in the device. The measurements may be, for example, hash values computed of software components or configuration files loaded. The TPM comprises a number of Platform Configuration Registers (PCR). For example, a subset of the PCRs is dedicated to the operating system of the device, to which the TPM is connected, whereas the rest are dedicated to the standard applications in the device. The standard applications comprise, for example, the protocol stacks and a number of communication applications. Initially, before the system is booted, the PCRs have zero or other initial values. As a software component is loaded, a first hash value is computed of the software component code. The first hash value and the initial value of the PCR associated with the software component are used as arguments in a hash function to compute a new value, that is, a second value for the PCR. A number of different software components may be associated with a single PCR. Subsequently, always when a new software component associated with the PCR is loaded or updated, the PCR is extended, which means that the current PCR value is used together with a hash value computed of the new software component as an argument for a hash function to compute the new value for the PCR. The value of a PCR is never set directly to a new value without taking into consideration the existing value.
The TPM module and the remote attestation protocol specified by the TCG group enable interactive remote attestation. In interactive remote attestation the target device, such as the VPN gateway, sends a challenge to the remote device. The TPM module on the remote device reads its internal platform configuration registers (PCRs) that contain measurements of the software the remote device is running. After that, the TPM module signs the PCR values and the received challenge using its internal key called Attestation Identity Key (AIK). The signed response containing the PCR values is sent back to the target device. The target device may then check that the remote device is running the correct software configuration by comparing the received PCR values against expected values. The target device gets a list of valid AIKs from a trusted third party. If the response was signed with a valid AIK, the target device knows that the response was generated by a proper TPM module and the received PCR values may be trusted.
Interactive remote attestation works in scenarios in which immediate end-to-end connectivity can be assumed between the remote and target devices. However, there are several situations in which this assumption is false. One example is store-and-forward messaging like e-mail, in which it may not be feasible to have intermediate forwarding nodes, that is, target devices in the attestation sense to interact with the original message sender, that is, the remote device in the attestation sense. Communication in rural areas is another example of Delay- and Disruption Tolerant Networking (DTN), in which immediate end-to-end connectivity is not always available.
The general problem is as follows: A sender S sends a message m to a recipient R. The message needs to be carried by several intermediaries D1, . . . , Dn before being delivered to R. Each Di and finally R may want to take measures to protect themselves from abuses like spam and flooding. One way to do this is to verify the authenticity of the sender. But this may not be possible or desirable, for example, due to privacy reasons. A complementary method is to verify that m was sent by a well-known software configuration trusted by the verifier, that is, Di or R. For example, the well-known software configuration may have built in mechanisms to prevent or at least report abuses. One such reporting mechanism is a message header stating how many messages were sent out in the last hour. What is needed is an efficient and secure mechanism for a verifier to check that m was indeed sent by a given well-known software configuration running on some possibly unknown sender's device.